從被動查詢到主動通知

Week 2 的日誌與 Week 3 的 Trace，都是「你先知道有問題，才去查」的工具。這週要處理的是另一個方向：怎麼在問題發生時就主動知道。這是 Cloud Monitoring 的角色。

三個核心元件

Metrics（指標）：時間序列的數值資料。Cloud Monitoring 會自動收集 GCP 資源的內建指標（CPU、記憶體、請求數），也支援自訂指標——Agent 場景真正重要的指標多半需要自訂，Day 20 會展開。

Dashboard（儀表板）：把多個指標組合成一個檢視畫面。設計得好的 Dashboard 應該讓人在十秒內判斷「現在有沒有問題」，而不是塞滿三十張圖表卻看不出重點。

Alerting Policy（告警政策）：定義「什麼條件下要通知誰」。這是三者中最需要仔細設計的——告警設太鬆會漏掉問題，設太緊會製造大量誤報，最後演變成沒人看告警。

指標的三種來源

內建指標：GCP 資源自動產生，不需額外設定。適用於 Day 4 提過的第一層（基礎設施層）。

Log-based Metrics：Day 7 提過的機制，把符合條件的日誌筆數轉成指標。這是把 Week 2 的日誌設計轉化為告警能力的橋樑——例如你在日誌記錄了「轉接人工」事件，就能轉成指標並設定告警。

自訂指標（Custom Metrics）：應用程式主動寫入的指標。適合需要記錄數值（而非事件計數）的場景，例如每次任務的品質分數。

一個常見的設計錯誤

很多團隊的 Agent 監控 Dashboard，第一版做出來全是基礎設施指標——CPU、記憶體、請求數。這些不是不重要，但它們回答不了「Agent 做得好不好」。如果你的 Dashboard 上沒有任何一個指標是關於任務品質的，那它監控的其實不是 Agent，只是 Agent 跑的那台機器。 Day 20 會處理這個問題。

這篇的檢查清單

• [ ] 現有 Dashboard 是否只有基礎設施指標，缺乏任務品質層級的指標？
• [ ] Week 2 設計的關鍵日誌事件，是否已轉成 Log-based Metrics？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。